fix(auth): get_access_token reflects current request in stateful sessions - #2675
Open
Epochex wants to merge 5 commits into
Open
Conversation
added 5 commits
August 1, 2026 22:39
There was a problem hiding this comment.
2 issues found across 3 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/mcp/server/runner.py">
<violation number="1" location="src/mcp/server/runner.py:231">
P2: Notification handlers in a stateful Streamable HTTP session can still read the session-creating request's token after a later authenticated notification. Scope `push_auth_context_from_request(ctx.request)`/`pop_auth_context()` around `_on_notify`'s middleware call too, so `get_access_token()` matches that notification's HTTP request.</violation>
</file>
<file name="tests/server/auth/test_get_access_token_streamable_http.py">
<violation number="1" location="tests/server/auth/test_get_access_token_streamable_http.py:66">
P2: This regression test creates and terminates a separate Streamable HTTP session for each token, so it passes even with the original stale-context bug. Keeping one `streamable_http_client`/`Client` open while changing the mutable auth token between tool calls would exercise later HTTP requests on the same stateful session.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| # including its response envelope. The pipeline never patches it up after | ||
| # the fact. | ||
| result = _dump_result(await call(ctx)) | ||
| auth_token = push_auth_context_from_request(ctx.request) |
There was a problem hiding this comment.
P2: Notification handlers in a stateful Streamable HTTP session can still read the session-creating request's token after a later authenticated notification. Scope push_auth_context_from_request(ctx.request)/pop_auth_context() around _on_notify's middleware call too, so get_access_token() matches that notification's HTTP request.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/mcp/server/runner.py, line 231:
<comment>Notification handlers in a stateful Streamable HTTP session can still read the session-creating request's token after a later authenticated notification. Scope `push_auth_context_from_request(ctx.request)`/`pop_auth_context()` around `_on_notify`'s middleware call too, so `get_access_token()` matches that notification's HTTP request.</comment>
<file context>
@@ -227,7 +228,11 @@ async def _inner(ctx: ServerRequestContext[LifespanT, Any]) -> HandlerResult:
# including its response envelope. The pipeline never patches it up after
# the fact.
- result = _dump_result(await call(ctx))
+ auth_token = push_auth_context_from_request(ctx.request)
+ try:
+ result = _dump_result(await call(ctx))
</file context>
| follow_redirects=True, | ||
| ) as http_client, | ||
| ): | ||
| transport_ctx = streamable_http_client(f"http://{host}/mcp", http_client=http_client) |
There was a problem hiding this comment.
P2: This regression test creates and terminates a separate Streamable HTTP session for each token, so it passes even with the original stale-context bug. Keeping one streamable_http_client/Client open while changing the mutable auth token between tool calls would exercise later HTTP requests on the same stateful session.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At tests/server/auth/test_get_access_token_streamable_http.py, line 66:
<comment>This regression test creates and terminates a separate Streamable HTTP session for each token, so it passes even with the original stale-context bug. Keeping one `streamable_http_client`/`Client` open while changing the mutable auth token between tool calls would exercise later HTTP requests on the same stateful session.</comment>
<file context>
@@ -0,0 +1,97 @@
+ follow_redirects=True,
+ ) as http_client,
+ ):
+ transport_ctx = streamable_http_client(f"http://{host}/mcp", http_client=http_client)
+ async with Client(transport_ctx) as client: # pragma: no branch
+ result = await client.call_tool("whoami", {})
</file context>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2208.
Stateful Streamable HTTP sessions start the server task group on the first request. Anyio copies the request contextvars into that long-lived task, so get_access_token() could keep returning the token from the session-creating request even when later requests send a different Authorization header.
This change pushes the authenticated user into the auth contextvar at request-dispatch time (using the ServerMessageMetadata.request_context threaded through the transport), and resets it after the handler returns.
Tests: